Nice!

But it was a little sad adding extra type annotations.

Sorry about that. Right now I'm trying to simplify the implementation above all else, which means cutting features.

But it's not clear to me why each is able to infer the type of the index to loop over when for isn't.

I can explain this one. The new type inference is forward-only and very local (there are arguments for this besides simplifying the implementation but that's another matter). each takes a table as an argument which carries an index set. By the time we reach the lambda argument to each we've seen that table so we know the index set. But we don't learn the index set for the for until we see how the index is used. A general principle of the new inference system is that we never infer things about a variable based on how it's used. Type inference follows data flow. It's the UTI principle: type information shouldn't flow backwards.

But please keep the friction reports coming regardless. I want to at least be aware of the cost I'm imposing on users with these choices.